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REMARKS 

In the Office Action dated December 28, 2007, claims 1-29 were pending. Claims 
1-8, 12-22, 26-29 were rejected under 35 U.S.C. §102(e) as being anticipated by Ishwar 
et al., Pub. No.: US 2004/0017816, (hereafter referred as, "Ishwar"). Claims 9-11 and 
23-25 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Ishwar in view 
of Kalkunte et al., Pub. No.: US 2002/0012345, (hereafter referred as "Kalkunte"). 

Independent claims 1, 15, and 29 are amended to clarify that the plurality of 
tunnels comprise a link aggregation, such as assignees " Ether Channel" . 

Claims 1-8, 12-22, 26-29 were rejected under 35 U.S.C. § 102(e) as being 
anticipated by Ishwar. Applicants respectfully traverse this rejection. They further 
reargue and reassert their arguments made in their previous amendment. 

Furthermore, as noted above, independent claims 1, 15, and 29 are amended to 
clarify that the plurality of tunnels comprise a link aggregation. The first element in claim 
1 requires: "creating a link aggregation comprising a plurality of tunnels across a 
computer network to connect a first computer to a second computer, the plurality of 
tunnels including a tunnel for each link in the link aggregation, said link aggregation 
capable of simultaneously supporting a plurality of transmission protocols". Iswar does 
not suggest or teach a link aggregation of tunnels. Rather, it is directed towards 
unconnected tunnels or VLANs. The present invention utilizes end-to-end tunnels or 
VLANs, but as a part of a link aggregation, such as assignee of this application's 
EtherChannel. A link aggregation is an aggregation of links. In the prior art, the link 
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aggregations were of Ethernet channels. In the present invention, the links are VLANs or 
tunnels. 

There are significant differences between the Ishwar tunnels or VLANs and the 
link aggregations presently claimed. First note that a single address is typically utilized to 
refer to a link aggregation comprising multiple links. In the case of a level 2 link 
aggregation, the single address is typically a media access control (MAC) address. In the 
case of level 3, it is typically an IP address. Thus, a single MAC address is used to 
designate or address multiple tunnels or links, whereas in Ishwar, a single link or tunnel 
has one or more MAC or IP addresses. Thus, in the present invention: "A connection is 
established through the computer network between the first computer . . . with a second 
computer ... using the plurality of tunnels" ([0011]). This is impossible in Ishwar, since a 
connection there translates into a single tunnel, with one (or more) addresses and not a 
plurality of tunnels. This link aggregation configuration is notable in the present 
invention from the repeated references to link aggregation and EtherChannel throughout 
the specification. 

The examiner seemed to assert in the latest Office Action that Ishwar taught link 
aggregation protocols. However, there is no mention, suggestion, or teaching, of a link 
aggregation (such as assignee's EtherChannel) in that reference. 

These elements are missing in the Ishwar reference. Applicants therefore 
respectfully submit that a prima facie case of anticipation has not been made, that this 
rejection is improper, and request that it be withdrawn. The remainder of the claims are 
dependent upon these claims, and should be allowable for the same reasons. 
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Furthermore, as to claims 3 and 17, Ishwar does not mention PAgP protocol and 
does not discuss or suggest a link aggregation of VLANs. These elements are missing in 
Ishwar. 

Furthermore, as to claims 4 and 18, Iswar does not mention UDLD protocol. 
Mention of LSP is not mention of UDLD. This element is missing from Ishwar. 

Furthermore, as to claims 5 and 19, Ishwar does not mention EtherChannel or 
Etherchannel ports. Additionally, EtherChannel ports are connected by links (typically 
Ethernet, but in this invention, VLANs) with corresponding EtherChannel ports. Ishwar 
FIG. 3 shows multiple VLANs from multiple devices coupled to a single SPED, which is 
coupled over a single connection to another SPED, which breaks up the traffic into two 
VLANs again. This is just the opposite of what is claimed here. These elements are 
missing from Ishwar. 

Furthermore, as to claims 6 and 20, no mention is made of multipont tunneling in 
the cited sections of Ishwar. Similarly, MPLS is not mentioned there. Rather, this section 
of Ishwar teaches away from this element, since it involves a single logical connection. 
This element is therefore missing from Ishwar. Claims 7, 8, 21, and 22 are dependent 
upon these claims and should be allowable for these additional reasons. 

Furthermore, as to claims 13 and 27, it was asserted that Ishwar disclosed 
multipoint protocol tunneling detection on a per-protocol basis ([0043]). But the cited 
section of Ishwar does not disclose this, nor does the Office Action explain how this 
might work in that cited section of Ishwar ([0043]). The only mention of protocol in that 
paragraph is in Multi-Protocol Label Switching (MPLS), and there is no reason to believe 
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that that involves multipoint protocol tunneling detection on a per-protocol basis. Thus, 
this element is missing from Ishwar. 

These additional elements are also missing from Ishwar, along with the elements 
missing from the independent claims and argued above. Applicants therefore respectfully 
submit that a prima facie case of anticipation has not been made, that the rejection of 
these claims is therefore improper, and request that it be withdrawn. 

Claims 9-11 and 23-25 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Ishwar in view of Kalkunte. Applicants respectfully traverse this 
rejection, and further point out that these claims are dependent upon the independent 
claims argued above and should be allowable for the same reasons. Furthermore, 
applicants reassert and reargue their arguments made in their previous amendment. 

Furthermore, as to claims 9 and 23, Kalkunte mentions an AGE TIMER, but does 
not mention or suggest what value to set it at. The purpose of the AGE TIMER in 
Kalkunte is "Dynamic Address Learning". This has no relationship to the use of the timer 
in the present invention (e.g. MPT problem detection [0022]), and thus, there is no reason 
to believe that Kalkunte would set its AGE TIMER to the value specified in this claim. 
The reason cited in the Office Action bears no relationship to either Kalkunte nor the 
present invention, but is obviously derived from the present invention, utilizing 
prohibited hindsight. This element is missing from the combined references. 

Furthermore, as to claims 10 and 24, it is argued by the Examiner that the Hit bit is 
utilized to purge ARL entries. But the rejection of claims 9 and 23 involved setting the 
Static bit, and not the Hit bit. There is no relationship shown by the examiner between 
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these two bits in Kalkunte. Besides, Kalkunte purges the ARL entry upon timeout, and 
does not drop all packets with other source MAC addresses. Furthermore, there is no 
showing of how the combined references would work together here, or indeed, why 
purging the ARL entry would result in dropped packets. Thus, these elements are also 
missing from the combined references. 

Furthermore, as to claims 1 1 and 25, it was asserted that Kalkunte teaches that if a 
new MAC address has to be learned and if the ARL table is full, then random non-static 
entry can be picked up. That is not what was claimed here, which was that after the timer 
expires the next source MAC address encountered is used at the next multipoint protocol 
tunneling reference. It was further asserted that it would have been obvious to imply logic 
of Kalkunte in the system of Ishwar, because once the aging timer is expired and packet 
arrives with a new source MAC address with hit bit (missing in the present invention), 
random non-static entry can be picked up to move to the next multipoint protocol 
tunneling reference for further processing. But this adds nothing of consequence to 
Ishwar. Besides, there is a distinct difference between the absolute "provides" of the 
presently rejected claims and the "can be picked up" in Kalkunte. In that case, it is only 
picked up if the ARL table is full. Thus, even if Kalkunte is implemented into Ishwar 
(and there is no reason to believe that would be possible or beneficial), the new source 
MAC address maybe inserted into the ARL table. It might not be. And there is no reason 
to believe that insertion into the ARL table would teach using the new source MAC 
address as the next multipoint tunneling reference. Indeed, the only reason that the next 
multipoint tunneling reference is relevant in the first place is because it is claimed and 
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shown by applicants. Neither cited reference operates this way, nor is it relevant for either 
one. Thus, prohibited hindsight is utilized here. Thus, these additional elements are also 
missing from the combined references. 

Applicants therefore submit that a prima facie case of obviousness has not been 
made for these claims, that this rejection is improper, and request that it be withdrawn. 

Applicants believe that the above-identified application is now in condition for 
allowance and such action is respectfully requested. 

If the Examiner has any questions regarding this application or this response, the 
Examiner is requested to telephone the undersigned at 775-586-9500. 



Respectfully submitted, 

SIERRA PATENT GROUP, LTD. 



Dated: February 26, 2008 



Sierra Patent Group, Ltd. 
1663 Hwy 395, Suite 201 
Minden, NV 89423 
(775) 586-9500 



/bruce e. hayden/ 
Bruce E. Hayden 
Reg. No.: 35,539 
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